![](https://raw.githubusercontent.com/easterCat/img-package/master/img/50038933-4c661980-0064-11e9-9eba-985fdcc3c821.png)

## 渲染

渲染：就是将数据和模版组装成 html

### 客户端渲染

- 客户端渲染模式下，服务端把渲染的静态文件给到客户端，客户端拿到服务端发送过来的文件自己跑一遍 js，根据 JS 运行结果，生成相应 DOM，然后渲染给用户。

- html 仅仅作为静态文件，客户端在请求时，服务端不做任何处理，直接以原文件的形式返回给客户端客户端，然后根据 html 上的 JavaScript，生成 DOM 插入 html。

> 前端渲染的方式起源于 JavaScript 的兴起，ajax 的大热更是让前端渲染更加成熟，前端渲染真正意义上的实现了前后端分离，前端只专注于 UI 的开发，后端只专注于逻辑的开发，前后端交互只通过约定好的 API 来交互，后端提供 json 数据，前端循环 json 生成 DOM 插入到页面中去。

#### 客户端渲染利弊

好处： 网络传输数据量小、减少了服务器压力、前后端分离、局部刷新，无需每次请求完整页面、交互好可实现各种效果

坏处：不利于 SEO、爬虫看不到完整的程序源码、首屏渲染慢（渲染前需要下载一堆 js 和 css 等）

### 服务端渲染

> 页面由服务端渲染过后直接返回 html 页面给前端，url 的变更会刷新整个页面，也就是以前的 php 和 jsp 模式

- 服务端在返回 html 之前，在特定的区域，符号里用数据填充，再给客户端，客户端只负责解析 HTML 。

- 服务端渲染的模式下，当用户第一次请求页面时，由服务器把需要的组件或页面渲染成 HTML 字符串，然后把它返回给客户端。客户端拿到手的，是可以直接渲染然后呈现给用户的 HTML 内容，不需要为了生成 DOM 内容自己再去跑一遍 JS 代码。使用服务端渲染的网站，可以说是“所见即所得”，页面上呈现的内容，我们在 html 源文件里也能找到。

#### 服务端渲染利弊

好处:首屏渲染快、利于 SEO、可以生成缓存片段，生成静态化文件、节能（对比客户端渲染的耗电）

坏处:用户体验较差、不容易维护，通常前端改了部分 html 或者 css，后端也需要修改。

### 对比

其实前后端的渲染本质是一样的，都是字符串的拼接，将数据渲染进一些固定格式的 html 代码中形成最终的 html 展示在用户页面上。 因为字符串的拼接必然会损耗一些性能资源。

如果在服务器端渲染，那么消耗的就是 server 端的性能。
如果是在客户端渲染，常见的手段，比如是直接生成 DOM 插入到 html 中，或者是使用一些前端的模板引擎等。他们初次渲染的原理大多是将原 html 中的数据标记（例如{{text}}）替换。

## 为什么使用服务端渲染，它解决的是什么问题

- 首屏加载快 相比于加载单页应用，我只需要加载当前页面的内容，而不需要像 React 或者 Vue 一样加载全部的 js 文件

- SEO 优化 对于单页应用，搜索引擎并不能收录到 ajax 爬取数据之后然后再动态 js 渲染出来的页面。

> 事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。A 网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。但性能在其次，不代表性能不重要。服务端渲染解决了一个非常关键的性能问题——首屏加载速度过慢。在客户端渲染模式下，我们除了加载 HTML，还要等渲染所需的这部分 JS 加载完，之后还得把这部分 JS 在浏览器上再跑一遍。这一切都是发生在用户点击了我们的链接之后的事情，在这个过程结束之前，用户始终见不到我们网页的庐山真面目，也就是说用户一直在等！相比之下，服务端渲染模式下，服务器给到客户端的已经是一个直接可以拿来呈现给用户的网页，中间环节早在服务端就帮我们做掉了，用户岂不“美滋滋”？

## 什么情况下使用服务端渲染？

通过服务端渲染的概念以及它的两个特点：首屏加载速度快、SEO 优化。
我们知道，服务端渲染其实就是由浏览器做的一些事情，我们放到了服务端去做，那么对于掘金、简书、CSDN、知乎等网站的搭建，这种在网上一搜搜出一堆东西的网站，SEO 做的很好，应该多少都用到服务端渲染了吧？当然，做服务端渲染成本是高昂的。
vue 全家桶或者 react 全家桶，都是推荐通过服务端渲染来实现路由的。
服务端渲染并非完全之策（服务器稀少而宝贵），关于首屏渲染体验以及 SEO 的优化方案很多，在不使用服务端渲染这个操作下，我们最好的处理方式就是找寻替代优化方案。

关于在 server 端还是在 browser 端渲染的选择，更多的是要看业务场景。

## 同构

一套代码既可以在服务端运行又可以在客户端运行，这就是同构应用。简而言之, 就是服务端直出和客户端渲染的组合, 能够充分结合两者的优势，并有效避免两者的不足。

高端点的词 Universal APP，为什么要同构，因为客户端渲染存在一个缺点，就是首屏加载过大文件或过多文件会变得特别慢，因此可以把首屏放在服务端来渲染来提升首屏速度，首屏加载过后路又开始交给客户端控制，又变成了 SPA 应用，整个代码都是用 JavaScript 来编写，服务端采用 nodejs。

### 同构优点

- 性能: 通过 Node 直出, 将传统的三次串行 http 请求简化成一次 http 请求，降低首屏渲染时间
- SEO: 服务端渲染对搜索引擎的爬取有着天然的优势，虽然阿里电商体系对 SEO 需求并不强，但随着国际化的推进, 越来越多的国际业务加入阿里大家庭，很多的业务依赖 Google 等搜索引擎的流量导入，比如 Lazada.
- 兼容性: 部分展示类页面能够有效规避客户端兼容性问题，比如白屏。

## Doc

[为什么现在又流行服务端渲染 html？](https://www.zhihu.com/question/59578433)

[服务端渲染（SSR)](https://juejin.im/post/5c068fd8f265da61524d2abc)

[D2 - 打造高可靠与高性能的 React 同构解决方案](https://zhuanlan.zhihu.com/p/32124393)